Secure privilege level execution and access protection

ABSTRACT

The subject disclosure is directed towards using one or more of hardware, a hypervisor, and privileged mode code to prevent system mode code from accessing user mode data and/or running user mode code at the system privilege level, or vice-versa. Also described is (in systems with a hypervisor) preventing non-hypervisor code from running in hypervisor mode or accessing hypervisor-only data, or vice-versa. A register maintained by hardware, hypervisor, or system mode code contains data access and execution polices for different chunks of addressable space with respect to which requesting entities (hypervisor mode code, system mode code, user mode code) have access to or can execute code in a given chunk. When a request to execute code or access data with respect to an address is received, the request is processed to determine to which chunk the address corresponds. The policy for that chunk is evaluated to determine whether to allow or deny the request.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. application Ser. No.15/369,874, filed Dec. 5, 2016, which is a continuation of U.S.application Ser. No. 13/918,852 filed on Jun. 14, 2013, now U.S. Pat.No. 9,530,000, issued on Dec. 27, 2016, and both are hereby incorporatedby reference herein for all intents and purposes.

BACKGROUND

Attacks on computer systems are well known. One of the early ways toprevent attacks (as well as to prevent poorly written code from causingproblems) was to run user applications in user mode code at a lowprivilege level, and run system (sometimes referred to as privileged,kernel or supervisor) mode code at a high privilege level.

In general, system mode code running at system privilege level canaccess virtually any computing resource whereas user mode code cannot.Thus, one common contemporary attack is based upon tricking system modecode via a bug into running user mode code with a system privilegelevel. Through various exploits such as buffer overflows, the systemmode code jumps into or returns to what is actually malicious user modecode that then takes over the flow of execution, with system modeprivileges. The attack is based on the concept that while user mode codecannot access system mode data or run in system mode, the converse isnot true.

Recent hardware features referred to as Supervisor Mode AccessPrevention (SMAP) and Supervisor Mode Execution Prevention (SMEP)attempt to control data and execution access of supervisor mode code.However, these features do not protect against a wide class of attacks,in part because of susceptibility to mistakes in the page tables.Moreover, these features deal with user mode versus supervisor mode, anddo not make any distinction for code that runs in hypervisor mode.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, various aspects of the subject matter described herein aredirected towards preventing (e.g., via logic such as in hardware or ahypervisor) access and/or execution by code running in another mode orrunning at a different privilege level. In one aspect, addressablememory space is separated into chunks, with at least some of the chunksassociated with policy settings that identify one or more executioncapabilities and/or one more access capabilities of the chunks. At leastone policy setting indicates whether code in the chunk is executable ata system privilege level or not, or whether data in the chunk isaccessible as system mode data or not. A request to execute code oraccess data is processed, with the request having an indication of aprivilege level of the request.

Enforcing whether code execution or data access is allowed for therequest is performed, e.g., by enforcement logic in hardware and/orsoftware. Enforcing includes identifying a chunk with which the requestis associated, accessing the policy settings to determine the executionor data access capability of the chunk, and allowing or denying therequest based upon the privilege level, whether the request is toexecute code or access data and the capability of the chunk with whichthe request is associated.

In one aspect, a hypervisor coupled to guest software includesenforcement logic (implemented in hardware and/or software) configuredto prevent other code from executing in another mode or at a higherprivilege level than a mode to which a source of the other codecorresponds. The enforcement logic evaluates a request from a sourcerelated to code execution at an address against execution capabilitydata maintained for chunks of address spaces, to determine whether theaddress corresponds to a chunk in which the source is allowed to executecode. In one aspect, the enforcement logic is further configured toevaluate a request from a source related to data access at an addressagainst data access information maintained for chunks of address spacesto determine whether the address corresponds to a chunk in which thesource is allowed to access data.

In one implementation, code execution and data access policies areenforced at a hypervisor and/or hardware, including by processing arequest related to code execution or data access to evaluate a source ofthe request and an address associated with the request against policysettings. The hypervisor and/or hardware determines whether the requestis allowed or denied for the source at the address associated with therequest.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 is a block diagram representing example components for enforcingdata access policies and code execution policies at a hypervisor logicor hardware logic coupled thereto, according to one exampleimplementation.

FIG. 2 is a representation of how addressable address space may bedivided into chunks, with a chunk identified by an bits within anaddress, in which the chunks are associated with data access policiesand code execution policies, according to one example implementation.

FIG. 3 is a representation of an example register that maintains pagestructure information within a chunk for use by a hypervisor or othersystem mode (e.g., most-privileged) code in maintaining and evaluatingdata access policies and code execution policies, according to oneexample implementation.

FIG. 4 is a representation of an example register that maintains chunkpolicy data for use by a hypervisor or other system mode (e.g.,most-privileged) code in maintaining and evaluating hypervisor dataaccess policies and code execution policies, according to one exampleimplementation.

FIG. 5 is a representation of an example register that maintains chunkpolicy data for use by a hypervisor or other system mode (e.g.,most-privileged) code in maintaining and evaluating user and system modedata access policies and code execution policies, according to oneexample implementation.

FIG. 6 is a flow diagram representing example steps that may be taken toallocate space from a hypervisor-selected chunk based upon a requestingentity and a type of request, according to one example implementation.

FIG. 7 is a flow diagram representing example steps that may be taken toenforce whether to allow or deny a data access request based upon anaddress associated with the request and a source of the requester,according to one example implementation.

FIG. 8 is a flow diagram representing example steps that may be taken toenforce whether to allow or deny a request related to code executionbased upon an address associated with the request and a source of therequester, according to one example implementation.

FIG. 9 is a block diagram representing an example non-limiting computingsystem and operating environment in which one or more aspects of variousembodiments described herein can be implemented.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards having the CPU software that controls the physicalallocation of memory control its own access and execution and the accessand execution of software running at lesser privilege levels. Examplesof software that controls physical memory allocation comprise ahypervisor that manages virtual machines/virtualization, or theoperating system when there is no hypervisor/virtualization.

In one aspect, access/execution is controlled regardless of anyinadvertent or overt actions of lesser privilege level software at anytime. Examples of this include enforcing user mode software to executein user mode only with no other access, and system mode software toexecute in system mode only with no other access. As a result, even if abug or other malicious attack attempts to cause system mode software tojump into or return to a user mode address, execution is prevented. Dataaccess may be similarly limited

In one aspect, access/execution of the code is controlled afterestablishing permitted access. For example, hypervisor code is only ableto execute in hypervisor-only mode, with no other access includinghypervisor access to other modes. Data read/write access is limited tohypervisor mode only, with no other access to system data or user modedata allowed.

To this end, the hypervisor and/or other system mode (e.g.,most-privileged) code links access capabilities to the privilege level,whereby logic (e.g., in hardware and/or in the hypervisor code) controlseach type of access separately using existing memory management, e.g.,at page granularity. As a result, this scheme has no direct impact onlesser privilege level software, and provides for compatibility withexisting architectures with minimal hardware change.

In one aspect, the machine's virtual memory address space is dividedinto a number of chunks, such as eight, e.g., using three bits of theaddress space as a chunk identifier (e.g., “tag”) or the like thatrefers to one of the chunks. Each chunk has attributes defined by thehypervisor/other system mode (e.g., most-privileged) code; e.g., onechunk may be designated for only user mode data pages, another for usermode execution pages. Another chunk may be designated for privilegedmode data pages, one for privileged mode execution pages, one forhypervisor mode data pages, one for hypervisor mode execution pages, andso on. Once established, the hypervisor other system mode (e.g.,most-privileged) code has the ability to lock these designations (e.g.,maintained in one or more machine state registers for the hypervisor toread) until the next reboot.

When memory is allocated, the hypervisor/other system mode (e.g.,most-privileged) code allocates space only from the chunk that appliesto the requesting entity, e.g., a user execute chunk for user mode codeallocation requests. When a request to access memory or execute codecomes in, enforcement logic (e.g., in the hypervisor and/or hardware)enforces the designation associated with the request, e.g., system codecan only execute in a system mode executable code chunk, hypervisor codecan only execute in a hypervisor mode executable code chunk, and so on.

It should be understood that any of the examples herein arenon-limiting. For example, a hypervisor is shown as establishing accesspolicies in a virtualized machine, however in a machine withoutvirtualization/a hypervisor, the operating system may perform similaroperations. Further, various configurations of chunks and registers areexemplified, but alternative configurations are feasible. As such, thepresent invention is not limited to any particular embodiments, aspects,concepts, structures, functionalities or examples described herein.Rather, any of the embodiments, aspects, concepts, structures,functionalities or examples described herein are non-limiting, and thepresent invention may be used various ways that provide benefits andadvantages in computer protection in general.

FIG. 1 shows a generalized block diagram in which guest virtual machines102 ₁-102 _(n) request access to physical memory (RAM) 104. In generaland as is known, a hypervisor 106 is responsible for mapping aguest-specified address to a guest physical address to the correctactual physical memory location in the RAM 104. The mapping is basedupon a two-level translation using guest page tables 108 and virtualpage tables 110. Known caching and other techniques are used to makethis translation more efficient.

Described herein is dividing the addressable space into chunks, alongwith the use of a set of one or more registers 112 by the hypervisor tocontrol access to data and/or code execution based upon the requestingentity. For example, when allocating memory space, consider that a guestrequests address space for user mode executable code. Using existingverification techniques, if the requesting entity (e.g., the guestoperating system for that user mode code) is verified, virtual addressspace is allocated from a particular chunk that designated as user modeexecutable code space, with the designation written to and tracked inthe register set 112. Note that the register set 112 register set maycomprise any accessible storage location that maintains execution and/ordata access policy settings that may be evaluated to determine whether asource that makes an execution-related request or data access request isallowed to perform the requested operation.

In one implementation, some number of bits (e.g., three) of each address(e.g., forty bits total) correspond to the chunk designation, e.g., asan chunk identifier (tag) that corresponds to one chunk. This example isgenerally represented in FIG. 2, where virtual address space (e.g., oneterabyte) is divided into chunks 222 (eight in this example), with thefirst m bits (three in this example) acting as an identifier of one ofthe corresponding chunks. In the example of FIG. 2, there are sevendifferent types of chunks 222 exemplified, namely execute user only,execute hypervisor only, execute system only, no execute user only R/W(data), no execute hypervisor only R/W (data), no execute system onlyR/W (data), and system only execute and R/W (data).

Further, note that one or more other chunks allow for otherdesignations, e.g., instead of hypervisor mode execute and hypervisormode R/W access (no execute), there may be a further distinction ofhypervisor mode system privilege level execute, hypervisor mode userprivilege level execute, hypervisor mode system data access/no-execute,and/or hypervisor mode user privilege level data access/no-executedesignations. Still other designations are feasible, such as to have achunk for digital rights management (DRM) data, a chunk for just-in-time(JIT) compiled code, and so on.

When the hypervisor 106 receives a code execution request or a dataaccess request from requesting code 224 along with the requested address226, whether from user mode code, system mode code or hypervisor modecode, the hypervisor 106 knows which entity is making the request andwhether the request is directed to data access or to code execution.Note that the hypervisor 106 allocated or otherwise assigned the memoryspace (e.g., including the upper three bits as exemplified herein) at anearlier time based upon the type of requesting entity. The enforcementlogic 107, which may be implemented in hardware and coupled to thehypervisor 106, (and/or may be in the hypervisor 106, shown via thedashed box), evaluates the upper three bits against the register set 112to determine whether the entity and the type of request is allowed forthis chunk. If so, the request is allowed to succeed, otherwise therequest is failed.

In one embodiment, the hypervisor 106 initially sets all guest pages inthe page table to no-execute via the execute/no-execute bit therein foreach page. When a request comes in to execute code, the enforcementlogic 107 checks the register to determine if execution is allowed atthe corresponding page address for this requester/address, based uponthe registry attributes for the type of requester, and either allows ordenies the request. If allowed, the enforcement logic 107 also sets thepage bit in the page table at that time to “execute” status so that thecode may execute.

Note that instead of (or in addition) to a register or the like, it isfeasible for the page tables to have one or more additional capabilitybits that specify data access and code execution according to privilegelevels and/or modes. In other words, a programmable set of accessdesignations may be added to the page tables that specify physicalallocation of memory; a typical implementation modifies hypervisor pagetables and adds additional information to cache, although guestoperating system and user page tables, as well as caching, areunaffected.

However, such capability bits are not readily available with existingtechnologies, and thus existing page table schemes and/or existinghardware architectures need modification to implement such a capabilitybit set, making a new architecture solution less-than-desirable comparedto using an existing architecture. Moreover, as page tables aremaintained in main memory, such page table bits are also susceptible toattack or other corruption; in contrast, in one implementation, theregister set 112 may be maintained in a processor location (e.g.,processor hardware registers/model specific registers/CPU memory notsubject to tampering) for additional security.

Moreover, the register set 112 may be locked. More particularly, thehypervisor 106 may write the attributes (e.g., represented by bitvalues) regarding designation of the chunks to the register set 112, andthen lock the register set 112. Once locked, not even the hypervisor 106can change the locked register set 112 during its operation (theregister set remains locked until the next unlock event, which may be areboot). Note that in a typical usage pattern, the hypervisor 106 setsup and locks the register set 112 as soon as possible after thehypervisor 106 begins running, so that any subsequently executed bugs orerrors in hypervisor code cannot change the register set. As a result, asubsequent bug in the hypervisor code cannot be used to exploit theregister-based security scheme, for example.

Note that the use of m bits (e.g., three bits) of the address 226conveniently allows for efficient register lookup by the enforcementlogic 107. This scheme results in each virtual chunk being the samesize; e.g., with a three-bit identifier, each chunk is one-eighth of theaddressable space after subtracting the three tag bits, e.g., 2³⁷ bitsfor a forty bit address. Given the typical amounts of physical RAM usedin contemporary devices and the amounts of RAM that typical programsneed to address, reducing the addressable space by three bits is notproblematic. Indeed, if desired even more bits may be used to allow formore chunk designations without running out of addresses for any type ofrequestor in a typical computing machine.

Notwithstanding, other schemes may be used, including a scheme havingchunks of unequal size. For example, the hypervisor/register may trackchunk boundaries as well as the designated capabilities of each chunk.Another scheme (one that basically allows for “chunks” of unequal sizeby combining chunks) may be to divide the addressable memory space intomore chunks than needed for the various types of designation (at thecost of more identifier bits), but give certain chunks the sameattributes/capabilities in the register set, with addressable memoryallocated from among these same type of chunks accordingly. For example,there may be three chunks designated for “execute user mode only” andonly one chunk for “execute hypervisor mode only.” In this way, morechunk granularity is provided (as well as more possible chunkdesignations), such that an entity such as the hypervisor uses less ofthe addressable space relative to the addressable space useable byanother entity.

As can be readily appreciated, the chunk identifier and registermechanism described herein avoids the need for any changes to existingpage tables and/or any changes to the hardware caching of page tableinformation. Pages of memory are assigned a desired chunk as part oftheir physical address to select the desired access designations. Thehypervisor 106 controls these designations, and can lock various ones(or all) until the next reboot.

Note that existing access designations in the CPU architecture continueto operate unaffected, but are overridden by the new designations whenthe new designations are more restrictive. For example, consider thatthe execute bit for a page in the page tables allows code execution onthat page, but the page is in a chunk that the hypervisor has designatedas no execute. The enforcement logic 107, which handlesexecution-related requests, prevents code execution regardless of theexecute bit setting for that page. Among other benefits, this preventsbugs, corruption or errors in the page tables from allowing improperexecution.

One example implementation described herein is of a CPU architecturethat supports forty (or more) physical address bits in its page tablesand memory management hardware. Such architecture provides (at least)one terabyte of addressable space, which is significantly more than theamount of physical memory generally attached to the CPU. In oneembodiment, the upper three address bits are used to select one of eightprogrammable sets of access designations. The remaining (e.g.,thirty-seven) bits address the memory space within each set.

As described herein, in one embodiment, identified chunks of the addressspace are used to select a programmable set of access designations. Inone implementation, at least one chunk contains (but is not necessarilylimited to) hypervisor code and data. More particularly, the amount ofmemory used for hypervisor code and data is relatively small, and thusvia a particular register 330 (FIG. 3) of the register set 112 alongwith one chunk is configured with individual page access designationsfor a part of the chunk. In one example implementation, two megabytepages in the low portion of one of the chunks have individual accessdesignations in hypervisor registers that apply when in hypervisor mode.

Note that there may be multiple sets of policies for a chunk or part ofa chunk of actual memory. Part of a chunk may have policies, includingbecause a chunk part may encompass the use of page tables to mapindividual pages of a chunk to different hardware and software (thread)requesters.

In one example implementation, one of the chunk parts is reserved forregisters and other non-main memory storage accessible with CPU load andstore operations. Accessing non-main memory storage with CPU load andstore operations is commonly known as Memory-Mapped IO (MMIO). Asdescribed above, the registers alternatively may be in a more securememory location external to main memory.

Various registers may be present for various purposes, including one forhypervisor access control (ASID zero). For example, in an implementationexemplified in FIG. 3, one of the registers of the register set 112comprises a hypervisor-only sixty-four (64) bit machine state register330, comprising two bits for each of the first thirty-two (32)two-megabyte pages of one of the chunk, shown in FIG. 3 as chunk 332. Inother words, part of the chunk 332 is subdivided via another register330 for use only by the hypervisor 106. There is one bit per page thatallows hypervisor execution on the corresponding page if set to one (1),and disallows execution if cleared to zero (0). The other bit allowshypervisor read/write access if set to one (1), and disallows if zero(0). Thus, in the example of FIG. 3, Page 0 has an execution bit E0(that may be set to one or zero) and a read/write bit RW0 (which may beset to one or zero), and so on for each page up to page 31. Note thatthe execution bits and read/write bits are exemplified in FIG. 3 asalternating, however it is feasible to have thirty two-execution bits insequence followed by thirty read/write bits, and indeed, the registerbits may be arranged in any workable order.

The hypervisor 106 can lock the state of the thirty-two (32) executionbits, and/or separately lock the thirty-two (32) read/write bits, untilthe next reset (reboot) if the hypervisor chooses to do so. The register330 may be initialized to zero by resets, but this is not required.

Another register is for controlling hypervisor execution and read/writeaccess to each of the chunks. For example, if there are eight chunks, ahypervisor-only machine state register with eighteen (18) active bitsmay be used, as generally represented by the register 440 in FIG. 4 thatis associated with the eight chunks 442 (chunk0 to chunk7). As can beseen in this example, there are two bits for each chunk; one bit allowshypervisor execution in the chunk corresponding to the identifier if setto one (1), or disallows execution if zero (0). The other bit allowshypervisor read/write access if set to one (1), or disallows read/writeaccess if zero.

One of the remaining two bits (Lock E) is locks the state of theexecution enable bits in the register 330 of FIG. 3 and the register 440(FIG. 4) when set to one. The other bit (lock RW) locks the state of theread/write enable bits in the register 330 of FIG. 3 and the register440 (FIG. 4) if set to one. The lock bits are initialized to zero byresets. The other bits may be initialized to zero by resets, but this isnot required.

With respect to other (non-hypervisor) access control (ASID non-zero),FIG. 5 shows a hypervisor only thirty-two-bit machine state register 550with four bits for each of the eight chunks 442. One bit allows CurrentPrivilege Level (CPL)=3 (Ring 3 in x86 architectures) execution if setto one, and disallows execution if zero. A second bit allows CPL=0, 1, 2(Ring 0, 1 or 2) execution if set to one, and disallows execution ifzero. A third bit allows CPL=3 (Ring 3) read/write if set to one, anddisallows read-write when zero. The fourth allows CPL=0, 1, 2 read/writeif set to one and disallows if zero. The register 550 may be initializedto zero by resets, but this is not required. The register 550 may bepart of the virtual machine state stored in the virtual machine controlblock, and loaded and stored as part of VMRUN/#VMEXIT and VMLOAD/VMSAVE,but this is also not required.

FIG. 6 is a flow diagram summarizing example steps that may be taken bya hypervisor/other system mode (e.g., most-privileged) code with respectto a memory allocation request, beginning at step 602. As describedabove, the hypervisor may clear any page table bits as desired, e.g.,those that are related to allowing guest execution, as represented atstep 604. In this way, no guest is able to execute code withoutenforcement logic approval.

Note that at system startup, non-hypervisor code and data may be firstloaded into a chunk that allows no execution. If execution is requested,and the enforcement logic 107 (FIG. 1) allows execution for the request,the code may be copied into a chunk that is appropriate for executingthe code based upon the system or user privilege level as appropriatefor the requester. That is, the guest informs the hypervisor whetheruser or system mode execution is desired, and based upon thecredentials, the enforcement logic 107 allows the request by copying thecode into the user or system chunk. Execution is then allowed with theexecution bit in the page tables set as appropriate, e.g., a page at atime.

Step 606 determines whether the request is “OK” according to any numberof criteria. For example, space needs to be available to allocate or therequest is failed. Moreover, one or more various mechanisms may be usedto ensure that the requesting entity is authorized to make the request,e.g., that the guest operating system is from a legitimate source, hasnot been tampered with, and/or the like. For example, guest code maymake a hypercall to the hypervisor, which checks a signature of thecaller to authorize the request. If not, step 608 fails the request.

If the request is “OK” according to the one or more evaluation criteriaat step 606, then step 610 is executed to allocate the space. The bitsthat are included in the returned allocation are set to the values thatcorrespond to the request, e.g., an allowed user mode execute allocationrequest has the bits set to the chunk corresponding to user mode executeallocation as established in the bits within the register set for thischunk, e.g., (1, 0, 0, 0 in the scheme above), that is, Ring 3 execute,Ring 0, 1, 2 no-execute, Ring 3 no read/write, Ring 0, 1, 2 noread-write. Thereafter, via the identifier part of the address, any useof this address is limited by the hypervisor to only Ring 3 (user mode)code execution.

FIG. 7 shows example logic with respect to enforcing a read/write dataaccess request received at step 702 by the hypervisor. At step 704, theenforcement logic extracts the identifier bits from the addressaccompanying the request, and uses these bits to access the registerset. For non-hypervisor access control, the register 550 may be read,for example, while for hypervisor access control, further registers(e.g., 330 and 440) may be read.

Step 706 represents evaluating whether read/write is allowed by theregister settings for this address. If not step 708 denies the request.If so, step 710 allows the request; note that the page table bit mayfurther deny a write.

FIG. 8 is directed towards enforcement of an execution request receivedat step 782 802 by the hypervisor. At step 804, the enforcement logicextracts the identifier bits from the address accompanying the request,and uses these bits to access the register set. For non-hypervisoraccess control, the register 550 may be read, for example, while forhypervisor access control, further registers (e.g., 330 and 440) may beread.

Step 806 represents evaluating the register settings to determinewhether execution is allowed by for this address. If not, step 808denies the request, such as by clearing one or more page table bits. Ifso, step 810 sets the bit to one (which may still be cleared to zero viastep 602 of FIG. 6) to allow the write in the page table for theappropriate page, and allows the request.

Example Operating Environment

FIG. 9 illustrates an example of a suitable computing and networkingenvironment 900 into which the examples and implementations of any ofFIGS. 1-8 as well as any alternatives may be implemented. The computingsystem environment 900 is only one example of a suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 900 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the example operating environment 900.

The invention is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to: personal computers, server computers, hand-heldor laptop devices, tablet devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, and so forth, whichperform particular tasks or implement particular abstract data types.The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in local and/or remotecomputer storage media including memory storage devices.

With reference to FIG. 9, an example system for implementing variousaspects of the invention may include a general purpose computing devicein the form of a computer 910. Components of the computer 910 mayinclude, but are not limited to, a processing unit 920, a system memory930, and a system bus 921 that couples various system componentsincluding the system memory to the processing unit 920. The system bus921 may be any of several types of bus structures including a memory busor memory controller, a peripheral bus, and a local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

The computer 910 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by the computer 910 and includes both volatile and nonvolatilemedia, and removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by the computer 910. Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media. Combinations of the any of the above may also beincluded within the scope of computer-readable media.

The system memory 930 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 931and random access memory (RAM) 932. A basic input/output system 933(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 910, such as during start-up, istypically stored in ROM 931. RAM 932 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 920. By way of example, and notlimitation, FIG. 9 illustrates operating system 934, applicationprograms 935, other program modules 936 (e.g., a hypervisor) and programdata 937.

The computer 910 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 9 illustrates a hard disk drive 941 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 951that reads from or writes to a removable, nonvolatile magnetic disk 952,and an optical disk drive 955 that reads from or writes to a removable,nonvolatile optical disk 956 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the example operating environment include, butare not limited to, magnetic tape cassettes, flash memory cards, digitalversatile disks, digital video tape, solid state RAM, solid state ROM,and the like. The hard disk drive 941 is typically connected to thesystem bus 921 through a non-removable memory interface such asinterface 940, and magnetic disk drive 951 and optical disk drive 955are typically connected to the system bus 921 by a removable memoryinterface, such as interface 950.

The drives and their associated computer storage media, described aboveand illustrated in FIG. 9, provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 910. In FIG. 9, for example, hard disk drive 941 is illustratedas storing operating system 944, application programs 945, other programmodules 946 (e.g., hypervisor code) and program data 947. Note thatthese components can either be the same as or different from operatingsystem 934, application programs 935, other program modules 936, andprogram data 937. Operating system 944, application programs 945, otherprogram modules 946, and program data 947 are given different numbersherein to illustrate that, at a minimum, they are different copies. Auser may enter commands and information into the computer 910 throughinput devices such as a tablet, or electronic digitizer, 964, amicrophone 963, a keyboard 962 and pointing device 961, commonlyreferred to as mouse, trackball or touch pad. Other input devices notshown in FIG. 9 may include a joystick, game pad, satellite dish,scanner, or the like. These and other input devices are often connectedto the processing unit 920 through a user input interface 960 that iscoupled to the system bus, but may be connected by other interface andbus structures, such as a parallel port, game port or a universal serialbus (USB). A monitor 991 or other type of display device is alsoconnected to the system bus 921 via an interface, such as a videointerface 990. The monitor 991 may also be integrated with atouch-screen panel or the like. Note that the monitor and/or touchscreen panel can be physically coupled to a housing in which thecomputing device 910 is incorporated, such as in a tablet-type personalcomputer. In addition, computers such as the computing device 910 mayalso include other peripheral output devices such as speakers 995 andprinter 996, which may be connected through an output peripheralinterface 994 or the like.

The computer 910 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer980. The remote computer 980 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 910, although only a memory storage device 981 has beenillustrated in FIG. 9. The logical connections depicted in FIG. 9include one or more local area networks (LAN) 971 and one or more widearea networks (WAN) 973, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 910 is connectedto the LAN 971 through a network interface or adapter 970. When used ina WAN networking environment, the computer 910 typically includes amodem 972 or other means for establishing communications over the WAN973, such as the Internet. The modem 972, which may be internal orexternal, may be connected to the system bus 921 via the user inputinterface 960 or other appropriate mechanism. A wireless networkingcomponent such as comprising an interface and antenna may be coupledthrough a suitable device such as an access point or peer computer to aWAN or LAN. In a networked environment, program modules depictedrelative to the computer 910, or portions thereof, may be stored in theremote memory storage device. By way of example, and not limitation,FIG. 9 illustrates remote application programs 985 as residing on memorydevice 981. It may be appreciated that the network connections shown areexamples and other means of establishing a communications link betweenthe computers may be used.

An auxiliary subsystem 999 (e.g., for auxiliary display of content) maybe connected via the user interface 960 to allow data such as programcontent, system status and event notifications to be provided to theuser, even if the main portions of the computer system are in a lowpower state. The auxiliary subsystem 999 may be connected to the modem972 and/or network interface 970 to allow communication between thesesystems while the main processing unit 920 is in a low power state.

Conclusion

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

What is claimed is:
 1. A method comprising: separating addressablememory space into chunks, in which zero or more of the chunks addressthe same physical storage in whole or part as another chunk, and inwhich at least some of the chunks are associated with policy settingsthat identify one or more execution capabilities or one or more accesscapabilities of the chunks, or both, and including at least one policysetting that indicates whether code in the chunk is executable at asystem privilege level or not, or whether data in the chunk isaccessible as system mode data or not, and enforcing whether codeexecution or data access is allowed for a request, in which the requestindicates whether the request is to execute code or access data and anindication of a privilege level of the request, including by identifyinga chunk with which the request is associated, accessing the policysettings based upon the request to determine the execution or dataaccess capability of the chunk, and allowing or denying the requestbased upon the privilege level, whether the request is to execute codeor access data and the capability of the chunk with which the request isassociated.
 2. The method of claim 1 further comprising receiving therequest by a hypervisor or system mode code, and wherein enforcingwhether code execution or data access is allowed for the request isperformed by enforcement logic.
 3. The method of claim 1 wherein theprivilege level of the request corresponds to the system privilegelevel, wherein the policy settings indicate that the code in the chunkwith which the request is associated is not executable at the systemprivilege level or data in the chunk is not accessible by system modecode, or both, and denying the request.
 4. The method of claim 1 furthercomprising assigning an identifier to each chunk, in which theidentifier for a chunk is part of an address within the addressablememory space for that chunk.
 5. The method of claim 1 whereinidentifying the chunk with which the request is associated comprisesdetermining the chunk from an address associated with the request. 6.The method of claim 1 further comprising (a) writing the policysettings, including writing at least one policy setting that indicateswhether the code in the chunk is executable at a user privilege level ornot, or whether data in the chunk is accessible as user mode data ornot, or both, or (b) writing the policy settings, including writing atleast one policy setting that indicates whether the code in the chunk isexecutable in a hypervisor mode, or whether data in the chunk isaccessible as hypervisor mode data or not, or both, or both (a) and (b).7. The method of claim 1 further comprising subdividing at least onechunk into page structures, and wherein the policy settings includesdata that identifies execution capabilities or one more accesscapabilities of the page structures, or both execution capabilities andone more data access capabilities of the page structures.
 8. The methodof claim 1 further comprising locking at least part of the policysettings.
 9. The method of claim 8 wherein locking at least part of thepolicy settings comprises locking by hardware or software where the lockor locks are enforced by hardware, or by a hypervisor orhigher-privileged software than software that set a particular lock. 10.A system comprising: enforcement logic configured to prevent code fromexecuting in another mode or at a different privilege level than a modein which the code is intended to execute, and the enforcement logicconfigured to evaluate a request from a source related to code executionat an address against execution capability data maintained for chunks ofaddress spaces to determine whether the address corresponds to a chunkin which the source is allowed to execute code.
 11. The system of claim10 wherein the enforcement logic is incorporated in hardware orincorporated into a hypervisor or system mode code, or a combinationthereof, and wherein the source of the request comprises user mode code,system mode code, or hypervisor mode code.
 12. The system of claim 10wherein the enforcement logic is further configured to evaluate arequest from a source related to data access at an address against dataaccess information maintained for chunks of address spaces to determinewhether the address corresponds to a chunk in which the source isallowed to access data.
 13. The system of claim 10 wherein a subset ofbits of the address identifies a chunk of a plurality of equal sizechunks to which the address corresponds.
 14. The system of claim 10wherein at least two of the chunks of address spaces are different sizesfrom one another.
 15. The system of claim 10 wherein at least part ofthe capability data is maintained in a register set in memory or in aprocessor location.
 16. The system of claim 10 wherein the capabilitydata for a chunk includes information that indicates whether chunk codeis executable at user privilege level only, at system privilege levelonly or in hypervisor mode only.
 17. The system of claim 10 wherein thecapability data for a chunk includes information that indicates whetherchunk data is accessible at user privilege level only, at systemprivilege level only or in hypervisor mode only.
 18. One or morecomputer-readable storage media having computer-executable instructions,which when executed perform steps, comprising enforcing code executionand data access policies at enforcement logic, including processing arequest related to code execution or data access to evaluate a source ofthe request and an address associated with the request against policysettings to determine whether the request is allowed or denied for thesource at the address associated with the request.
 19. The one or morecomputer-readable storage media of claim 18 wherein the source of therequest comprises system mode code, wherein the address corresponds to achunk of addressable space designated as user mode only or hypervisormode only in policy data corresponding to the code execution and dataaccess policies, and wherein enforcing the code execution and dataaccess policies comprises denying the request.
 20. The one or morecomputer-readable storage media of claim 18 wherein the source of therequest comprises hypervisor mode code, wherein the address correspondsto a chunk of addressable space designated as user mode only or systemmode only in policy data corresponding to the code execution and dataaccess policies, and wherein enforcing the code execution and dataaccess policies comprises denying the request.